รีสตาร์ทเซอร์วิส Aruba CX

คู่มือฉบับย่อสำหรับ hpe-restd และ yang-resolverd

💡 เซอร์วิสเหล่านี้คืออะไร?

`hpe-restd` (HPE REST Daemon)

ประตูหลักสำหรับการจัดการสวิตช์ผ่าน REST API, Web UI, และการเชื่อมต่อกับ Aruba Central จัดการการยืนยันตัวตน, เซสชัน, และการแจ้งเตือนต่างๆ

`yang-resolverd`

จัดการและซิงโครไนซ์ข้อมูลสวิตช์ตามโมเดลข้อมูล YANG ทำให้ข้อมูลที่แสดงบน Aruba Central และระบบจัดการอื่นๆ ถูกต้องและเป็นปัจจุบัน

🤔 เมื่อไหร่ที่ควรพิจารณารีสตาร์ท?

อาการสำหรับ `hpe-restd`

  • สวิตช์ออฟไลน์ใน Aruba Central
  • Web UI ไม่ตอบสนองหรือล้มเหลว
  • REST API ใช้งานไม่ได้
  • `hpe-restd` ขัดข้อง (มี Core Dump)

อาการสำหรับ `yang-resolverd`

  • ข้อมูลใน Aruba Central ไม่ถูกต้อง (เช่น รายการ Client ผิดพลาด)
  • ข้อมูลสวิตช์ใน NMS อื่นๆ ล้าสมัย

🛑 หยุด! ข้อควรระวังก่อนรีสตาร์ท!

⚙️ ขั้นตอนการรีสตาร์ทเซอร์วิส (How-To)

1

เข้าถึง CLI

เชื่อมต่อสวิตช์ผ่าน Console หรือ SSH (สิทธิ์ Manager)

2

เข้า Diagnostic Shell

start-shell
3

ยกระดับสิทธิ์ (ถ้าจำเป็น)

sudo bash
4

สั่งรีสตาร์ทเซอร์วิส

สำหรับ `hpe-restd`:

systemctl restart hpe-restd

สำหรับ `yang-resolverd`:

systemctl restart yang-resolverd
5

ออกจาก `sudo bash`

exit
6

ออกจาก Diagnostic Shell

exit

⚠️ ผลกระทบที่คาดว่าจะเกิดขึ้น

ระหว่างรีสตาร์ท `hpe-restd`

  • Web UI, REST API, Aruba Central หยุดชะงักชั่วคราว
  • เซสชันการจัดการที่มีอยู่ถูกยกเลิก
  • ไม่กระทบ Data Plane (การส่งต่อข้อมูล)

ระหว่างรีสตาร์ท `yang-resolverd`

  • ข้อมูลใน Central/NMS อาจไม่ถูกต้องชั่วคราว
  • Data Subscriptions อาจต้องสร้างใหม่
  • ไม่กระทบ Data Plane (การส่งต่อข้อมูล)

ตรวจสอบสถานะเซอร์วิสหลังรีสตาร์ทด้วย systemctl status <service_name> และยืนยันว่าปัญหาได้รับการแก้ไข

❓ ถ้ารีสตาร์ทแล้วยังไม่หาย?

หากปัญหายังคงอยู่หรือเกิดขึ้นซ้ำๆ อาจมีสาเหตุที่ซับซ้อนกว่านั้น:

✅ ประเด็นสำคัญ (Key Takeaway)

สถาปัตยกรรมแบบโมดูลาร์ของ ArubaOS-CX ช่วยให้สามารถรีสตาร์ทเซอร์วิสเฉพาะส่วนได้ ซึ่งช่วยลดผลกระทบต่อระบบโดยรวมและเพิ่มความพร้อมใช้งานของเครือข่าย